Add automated release workflow #2586

ZzEeKkAa · 2024-05-24T23:18:59Z

Some of the upstream PRs are getting backported to the llvm_release_* branches, but those changes are never released. That prevents them from distributing as precompiled packages in various distributions like conda-forge and others. This PR targets this issue by creating automated workflow that is triggered once a month and generates automated releases for each such branch if there were changes since last release.

This PR

Adds workflow to generate releases every month from llvm_release_* branches in the format %llvm_major%.%llvm_minor%.%latest patch version +1%. For example:
- v18.1.1
- v17.0.2
- v17.0.1
- v14.0.1
- etc
Release description matches as close as possible to current releases. The only difference is that llvm versions is represented by two numbers, instead of three, because it is impossible to recover exact version. You can check out example of generated versions here (there are few releases from the original proposal): https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases
Workflow is set to be triggered once a month. It is also possible to trigger it manually from github actions UI.

Merge process

Merge the PR to main
Trigger workflow manually

Note

There is no need to backport changes to all branches, since workflow dispatch on schedule basis can be performed only from main branch.

Original proposal

I want to create this PR as a DRAFT and initial discussion about automated release. So I would like to hear feedback before merging the PR.

This PR:

Adds workflow to generate releases on every push to llvm_release_* branches in the format %llvm_version%.%commits since tag%. For example:
- v18.1.0.14
- v17.0.0.29
- v17.0.0.28
- v14.0.0.196
- etc
Release description matches as close as possible to current releases. You can check out example of generated versions here: https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases

Merge process:

Merge the PR to main
Backport the PR to all llvm_release_* branches

Open questions:

How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?
Are we okay with proposed version system?
[Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)
Is release description is okay?

Fixes: #1898
Fixes: #1508

CLAassistant · 2024-05-24T23:19:05Z

All committers have signed the CLA.

MrSidims · 2024-05-28T12:16:24Z

%llvm_version%.%commits since tag%

I'm slightly leaning towards setting the date of the release as it's easier to interpret by the one who reads it, but I'm not sure if it's an industry standard. But if we decide to release on every push, then I'd prefer to have number of commits encoded.

How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?

It feels like if we go with %commits since tag%, then releasing every push should be the way to go. Otherwise something like monthly releases looks good to me. @aratajew as IGC relies on the translator it might impact you. What would be your preference?

Is release description is okay?

IMHO automatically generated changelog is OK

[Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)

It's a good question. Such tags imho should be created manually, this automation should use the latest among them to create new patch/timestamp tags.

svenvh · 2024-05-28T12:19:47Z

Thanks for putting up a proposal!

How often should we do releases? On every push, weekly, bi-weekly, monthly, quarterly?

In #1898 it seems the proposal was monthly. That sounds good to me as a start, if we want more (or less) frequent releases we can always tune the interval later.

Are we okay with proposed version system?

Perhaps it would be best to follow semantic versioning, so we'd need to change the format slightly to comply. Or we could follow a different non-standard format to include the year+month.

[Kind of out of scope] Do we need to tag minor releases of llvm (like '14.0.6', etc)

We're not really following the patch releases of llvm since all 14.0.x releases should be compatible. For releases that break compatibility, we may need to decide when it happens perhaps?

Is release description is okay?

Following what we have done for current releases sounds good to me.

svenvh · 2024-05-28T12:21:00Z

It feels like if we go with %commits since tag%, then releasing every push should be the way to go.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

ZzEeKkAa · 2024-05-28T14:40:58Z

Thank you for the feedback! I love the idea to follow sem version specification, but package relies on llvm versioning. Should we then keep only major version and keep two others in sync with specification, or should we keep major and minor in sync with llvm and update only the third part on our own. Speaking of, should not llvm_release_180 be llvm_release_181?

Since these are automated release, keeping updated one number should be easier than updating two. So it should be something either 14.0.<automated> or 14.0.6.<automated>.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

What is the drawback? It seems like backport releases are not that frequent. since 14'th release there is less than 200 commits. What should we do if there are no updates since last release (e.g. a moth). Do clients what to have backports imminently on commit merge? Should we add option to manually release if such thing is critical? How would it fit into versioning?

svenvh · 2024-05-28T16:06:37Z

or should we keep major and minor in sync with llvm and update only the third part on our own.

Practically speaking this might be the easiest, because in this project itself we haven't really differentiated between minor and patch versions until now. So aligning major and minor to llvm seems reasonable. We should probably document that, maybe you can add a section to README.md too?

Speaking of, should not llvm_release_180 be llvm_release_181?

Good point, or even llvm_release_18.x following llvm's convention. Not sure if we should rename the current active branch, but we should keep this in mind when branching for llvm 19.

I think this would give a lot of "tag/release pollution", so I'd advise against that.

What is the drawback?

One concern is that it makes https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases harder to navigate. Right now it's an ordered list with the newest release on top. If we make an automatic release for every backport, the list will probably become large and "unordered" (it will reflect the order of branches getting a commit I suppose, which isn't very useful and might confuse folks).

What should we do if there are no updates since last release (e.g. a moth)

Don't create a new release in that case I'd say, as it doesn't add any value.

Should we add option to manually release if such thing is critical? How would it fit into versioning?

Manual releases should always remain an option. For versioning, any new release could follow a 18.1.(latest + 1) approach so there is no chance of versioning conflicts with a manual release.

ZzEeKkAa · 2024-05-28T18:02:49Z

list will probably become large and "unordered"

From my observation - it will be ordered semantically. The PR is made to apply latest tag only for most recent major release.

Summarizing everything, thing to be updated:

Release every month. If there are no updates since last release - do nothing.
Version system will be <(MAJOR LLVM).(MINOR LLVM).(latest + 1)>.

@svenvh who should approve this design so I can get the PR updated and ready to merge? And what are the next steps?

svenvh · 2024-05-29T07:16:39Z

@svenvh who should approve this design so I can get the PR updated and ready to merge? And what are the next steps?

Your plan sounds good to me. If @MrSidims also agrees you can start updating the PR. Not sure if anyone else from Intel has an opinion?

MrSidims · 2024-05-29T09:54:38Z

I'm fine with the schema, thanks for working on this! I'd like to also hear from @kurapov-peter as he is a potential customer of the feature.

ZzEeKkAa · 2024-05-29T14:04:49Z

Thank you @svenvh , @MrSidims ! I'll try to update the PR till the EOW. Should we wait for @aratajew ?

And something I've been thinking in terms of usability. Are all those backports ever introduce breaking compatibility? I'm thinking of other project using it through dynamic linking, could they pin project in the way version>=14.0.2;<15.0.0a0 for example?

kurapov-peter · 2024-05-31T09:50:22Z

I'm fine with the schema, thanks for working on this! I'd like to also hear from @kurapov-peter as he is a potential customer of the feature.

No preference as long as it's clear what's latest (and now it is)

asudarsa · 2024-05-31T11:22:13Z

This looks great and I read through the conversation thus far and it sounds like a nice addition. Will we be adding a README file on how to consume these packages or is that expected to be a known method?

thanks @ZzEeKkAa for adding this..

ZzEeKkAa · 2024-05-31T21:57:56Z

Thank you everybody! This PR is now ready to go. Just one open question that can be addressed in future releases (in other words, can we guarantee semantic versioning compatibility):

Are all those backports ever introduce breaking compatibility? I'm thinking of other project using it through dynamic linking, could they pin project in the way version>=14.0.2;<15.0.0a0 for example?

ZzEeKkAa · 2024-05-31T21:58:43Z

Will we be adding a README file on how to consume these packages or is that expected to be a known method?

I guess it is known method so far...

ZzEeKkAa · 2024-05-31T22:00:07Z

list will probably become large and "unordered"

From my observation - it will be ordered semantically.

It appears that is not strictly ordered...

ZzEeKkAa · 2024-06-03T15:33:24Z

@MrSidims @svenvh could you take a look and review/merge changes?

asudarsa

LGTM. Thanks

MrSidims

LGTM, thanks!

Can be done in a separate PR: IMHO it's a good idea to move a little bit groomed PR description into a separate doc placed here https://github.com/KhronosGroup/SPIRV-LLVM-Translator/tree/main/docs

@svenvh are you OK to merge this?

svenvh

Just one nit; it would indeed be nice to have some documentation too (adding to README.md?).

.github/workflows/patch-release.yaml

ZzEeKkAa · 2024-06-04T16:08:53Z

I've fixed comments and added brief description about automated releases in README. @MrSidims @svenvh does it meets what you had in mind for the doc or more detailed documentation needed to add to ./doc before merging the PR?

MrSidims · 2024-06-04T16:27:04Z

@ZzEeKkAa works for me, thanks!

svenvh

Thanks for the doc update!

ZzEeKkAa · 2024-06-05T15:07:57Z

Thank you for reviews and merging it!

Could you please go Actions -> Automated releases and trigger the workflow so that we get initial releases without waiting next month?

MrSidims · 2024-06-05T15:13:27Z

Sure! Lets see how it goes https://github.com/KhronosGroup/SPIRV-LLVM-Translator/actions/runs/9386710465

MrSidims · 2024-06-05T15:15:34Z

And it works, https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases/tag/v18.1.1! @ZzEeKkAa thanks a lot for your contribution!

asudarsa · 2024-06-05T17:58:18Z

Nice job @ZzEeKkAa and @MrSidims . This will be very useful. Thanks

Similarly to KhronosGroup/SPIRV-LLVM-Translator#2586 adds automated patch release generation. Examples of releases could be found in my fork: https://github.com/ZzEeKkAa/opencl-clang/releases For the final result look at https://github.com/ZzEeKkAa/opencl-clang/releases/tag/v17.0.5 . On other releases I've been playing around with release message. Fixes #537

MrSidims requested review from MrSidims, svenvh and asudarsa May 28, 2024 11:43

ZzEeKkAa and others added 2 commits May 31, 2024 17:44

Add automated release workflow

bd9adbc

Generate monthly releases of all llvm_release branches

7412ac1

ZzEeKkAa force-pushed the feature/automated_releases branch from bff56df to 7412ac1 Compare May 31, 2024 21:45

ZzEeKkAa marked this pull request as ready for review May 31, 2024 21:54

ZzEeKkAa mentioned this pull request May 31, 2024

Update to 18.1.0 conda-forge/llvm-spirv-feedstock#24

Merged

5 tasks

asudarsa approved these changes Jun 3, 2024

View reviewed changes

MrSidims approved these changes Jun 4, 2024

View reviewed changes

svenvh reviewed Jun 4, 2024

View reviewed changes

.github/workflows/patch-release.yaml Outdated Show resolved Hide resolved

ZzEeKkAa added 2 commits June 4, 2024 11:52

Fix typos/comments

b748ca0

Add readme about automated releases

b2c555b

svenvh approved these changes Jun 5, 2024

View reviewed changes

MrSidims merged commit 63e89a9 into KhronosGroup:main Jun 5, 2024
6 of 9 checks passed

ZzEeKkAa mentioned this pull request Jun 5, 2024

Patch releases for older versions conda-forge/llvm-spirv-feedstock#23

Open

ZzEeKkAa mentioned this pull request Jun 21, 2024

Add automated releases for llvm branches intel/opencl-clang#537

Closed

ZzEeKkAa mentioned this pull request Sep 27, 2024

Add automatic patch release generation intel/opencl-clang#551

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add automated release workflow #2586

Add automated release workflow #2586

ZzEeKkAa commented May 24, 2024 •

edited

Loading

CLAassistant commented May 24, 2024 •

edited

Loading

MrSidims commented May 28, 2024 •

edited

Loading

svenvh commented May 28, 2024

svenvh commented May 28, 2024

ZzEeKkAa commented May 28, 2024 •

edited

Loading

svenvh commented May 28, 2024

ZzEeKkAa commented May 28, 2024 •

edited

Loading

svenvh commented May 29, 2024

MrSidims commented May 29, 2024

ZzEeKkAa commented May 29, 2024

kurapov-peter commented May 31, 2024

asudarsa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented Jun 3, 2024

asudarsa left a comment

MrSidims left a comment

svenvh left a comment

ZzEeKkAa commented Jun 4, 2024

MrSidims commented Jun 4, 2024

svenvh left a comment

ZzEeKkAa commented Jun 5, 2024

MrSidims commented Jun 5, 2024

MrSidims commented Jun 5, 2024

asudarsa commented Jun 5, 2024

Add automated release workflow #2586

Add automated release workflow #2586

Conversation

ZzEeKkAa commented May 24, 2024 • edited Loading

This PR

Merge process

Note

Original proposal

CLAassistant commented May 24, 2024 • edited Loading

MrSidims commented May 28, 2024 • edited Loading

svenvh commented May 28, 2024

svenvh commented May 28, 2024

ZzEeKkAa commented May 28, 2024 • edited Loading

svenvh commented May 28, 2024

ZzEeKkAa commented May 28, 2024 • edited Loading

svenvh commented May 29, 2024

MrSidims commented May 29, 2024

ZzEeKkAa commented May 29, 2024

kurapov-peter commented May 31, 2024

asudarsa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented May 31, 2024

ZzEeKkAa commented Jun 3, 2024

asudarsa left a comment

Choose a reason for hiding this comment

MrSidims left a comment

Choose a reason for hiding this comment

svenvh left a comment

Choose a reason for hiding this comment

ZzEeKkAa commented Jun 4, 2024

MrSidims commented Jun 4, 2024

svenvh left a comment

Choose a reason for hiding this comment

ZzEeKkAa commented Jun 5, 2024

MrSidims commented Jun 5, 2024

MrSidims commented Jun 5, 2024

asudarsa commented Jun 5, 2024

ZzEeKkAa commented May 24, 2024 •

edited

Loading

CLAassistant commented May 24, 2024 •

edited

Loading

MrSidims commented May 28, 2024 •

edited

Loading

ZzEeKkAa commented May 28, 2024 •

edited

Loading

ZzEeKkAa commented May 28, 2024 •

edited

Loading